Instructions within modern computer programs may be organized for execution according to various instruction strings, or “threads”. Typically, a thread of instructions executing within a processing resource uses and/or generates a set of state information unique to, or at least associated with, a particular thread. However, threads may also share state information or other information, such as data to be operated upon by one or more threads, in which case information may need to be passed from one thread to another.
In typical shared memory microprocessors or processing systems, threads exchange information by one thread (transmitting thread) storing the information in a memory location, which can be read by another thread (receiving thread). Typically, a receiving thread may poll the memory location at various times to detect when the transmitting thread has updated the data. In some prior art implementations, a detection mechanism may detect when the shared information is written and may alert the receiving thread in response thereto.
In the latter case, in which a detection mechanism detects when the shared information is written to a memory location and alerts the receiving thread, some prior art techniques use special hardware detection logic that monitors, or “snoops”, the interconnect between microprocessors or between microprocessors and memory, such as DRAM. The detection logic may be configured to monitor for a command to a specific address to be transmitted across the interconnect, which may require detection logic for each memory location to be monitored.
Prior art techniques, such as those described above, can be costly in terms of die area and power. Furthermore, these prior art techniques, may not scale easily when monitoring updates to multiple memory locations, which can result in software development challenges.
There is prior art that covers mechanisms for reporting events directly to a user-level thread running on a microprocessor without requiring the traditional intervention of the operating system to notify of interrupts or exception cases. Such user-level interrupts or user-level exceptions are based on having a mechanism that saves sufficient information about the current state of the thread and redirects the thread to execute a pre-determined block of “handler” code to respond to the event. As part of the handler code the thread can perform any work it wishes to do and then return to the execution path it was on before the event. It may also choose to not return the execution path and instead continue to an entirely different set of tasks.